IBIS Macromodel Task Group Meeting date: 10 December 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that there had been a mix-up in the agenda email. He confirmed that we will have an ATM meeting on December 17th, and then the following meeting will occur on January 7th, 2020. ------------- Review of ARs: - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. - In progress. - Walter to prepare a draft BIRD based on the AMI_Impulse approach. - Done. - Bob to submit BIRD197.6 to the Open Forum. - Done. - Mike L. to send out a BIRD181.2_draft2 with the changes as noted in the meeting. - Done, sent to ATM several hours after the previous meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Review of the minutes for the November 26 meeting had been deferred at the December 3 meeting: Arpad asked for any comments or corrections to the minutes of the November 26 meeting. Walter moved to approve the minutes. Randy seconded the motion. There were no objections. Minutes for the December 3 meeting had been sent to ATM, but several participants had not received them. Curtis then noted that he discovered a spam filter had captured his. Randy moved that we wait until the next meeting to review them. Walter seconded. Justin sent the minutes out to ATM again as a precaution. ------------- New Discussion: BIRD198.1: Randy said he, Arpad, Bob, Mike L., and Walter had received a new response from the authors. Walter noted that he had been reviewing it, and he shared the response and summarized his view the important points: - The authors agree that [PDN Group] should be scoped under [Component]. - They don't like the use of the ISS syntax. - They think magnitude versions of typ/min/max don't make sense for this. - Walter and Randy noted that we are in agreement on this point. - There are questions about whether things align with process or not. - They provide several syntaxes. Walter reviewed the important points from their example #2: - Concept of a PDN domain - e.g., all the interconnect models between Vcc and Vss - rails could be bus_labels or signal_names - Their example provides 3 models for the domain. - PDN domain becomes something like a Model Selector. - Another PDN domain is defined for interconnect between Vdd and Vss. - again several different models Randy referred to a figure a on slide 7 of their response that helped illustrate their domain concept. He noted that they wanted to represent separate MOS and MIM caps. Randy noted that they're saying that the MOS caps are aligned with transistor process corners, but with the MIM caps there's no relationship to process corners so they have a Model Selector type approach for the MIM caps. Randy noted that both the MOS and MIM caps exist at the same time in parallel. They define separate PDN_for_VCC_MOS and PDN_for_VCC_MIM domains. Randy noted that since the MIM caps do not depend on any process-voltage-temperature conditions, their example 2 MIM domain repeats the same parameter values in all three columns. Randy suggested NA could be used instead for the repeated columns. Walter suggested the rail connections should be handled with two separate lines, Rail 1 and Rail 2, either of which could be a bus_label or a signal_name. Bob asked about pin_names, and Walter said the purpose of this proposal was supposed to be simplicity. People could use BIRD189 syntax if individual pin_name connections were required. Bob asked about how this could be included in multiple [Component]s. Randy agreed that you might have one die with several different packages. Bob suggested it might simply be repeated in multiple [Component]s, but this could be wasteful. Bob suggested the concept of pointing to a PDN model that is not scoped by [Component], but Arpad pointed out that this could be a problem if a PDN model refers to bus_labels or signal_names that are [Component] specific. Bob agreed this wasn't the solution. Arpad commented on Randy's suggestion that NA might be used for columns instead of repeating identical values. Arpad noted that we had to be very careful to explain the intent of NA, which actually stands for not-available. He noted that in some places the spec states that if min or max values are NA, then the EDA tool should fall back to the typ value. However, the meaning of "fall back" can be vague, especially with I/V curves and related parameters where you might violate Ohms law or something fundamental if you fall back in one area but not in another. Arpad noted that he would probably prefer to keep the repeated values instead. Randy noted that he understood Arpad's point. Radek asked if all 3 parameters C_pdn, R_pdn, R_leak were required. Walter and Randy said yes. Bob said it's a fixed topology, and we could define default rules if we wanted to do so. Radek said the BIRD should clearly state it one way or the other. Walter suggested he and Randy take an AR to redo the examples with a new syntax proposal and deal with NAs, bus_label vs. signal_name, etc. Randy agreed. Enabling Back-channel in Statistical Mode - AMI_Impulse BIRD: Walter reviewed his draft BCI Statistical BIRD based on AMI_Impulse(): - New parameter BCI_Training_Mode - Usage In - allowed values "Impulse", "GetWave", "Dual" - default is "GetWave" for backward compatibility - New AMI_Impulse() function - Like AMI_Init() in terms of arguments except: - AMI_memory argument is handled as it is in GetWave(). AMI_memory will contain the value returned by AMI_Init(). - Has BCI_parameters_in and BCI_parameters_out arguments that allow the EDA tool to pass BCI protocol defined strings between the Tx and Rx models' AMI_Impulse() functions. - EDA tools should keep a copy of the impulse_matrix before passing it to the initial call to AMI_Impulse() because the iterative calls to AMI_Impulse() will modify the impulse_matrix. - AMI_Impulse() will know the values of number_of_rows, aggressors, etc. from the original call to AMI_Init(). - Flow with a single Tx/Rx channel is defined - Flow with repeaters is defined - Every Tx and Rx in the entire chain must support the protocol. - The AMI_Init() portion of the flow is identical to that of the existing time domain repeater simulation flow. (IBIS 7.0, pg. 264) - The AMI_Impulse() portion follows the same flow, except with calls to AMI_Impulse() replacing the calls to AMI_Init() - BCI_parameters_out string is passed down the entire chain from one model to the next until the final Rx then loops back to the original Tx. Arpad asked if, in the case of redrivers, each Rx was optimizing its own Tx, i.e., optimizing channel-by-channel. Walter said he would typically expect the final Rx to optimize everything, but the BCI protocol could define it. Since we're passing the BCI_parameters_out along all the way down the chain, the first Rx could optimize the first Tx if it wanted to, or the last Rx could do it. It's up to the protocol itself. Ambrish asked if a model that supported "Dual" BCI_Training_Mode would still perform a GetWave() based BCI optimization starting with the initial channel IR. That is, the GetWave() optimization flow would not start with the final IR arrived at by the statistical BCI flow. Walter agreed. The GetWave() optimization flow does not use the final IR arrived at by the statistical optimization flow. - Walter: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Walter and Randy to work on a new iteration of a proposal for BIRD198. ------------- Next meeting: 17 December 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives